Can I Use PDATA in My E5 Application?

The Triscend E5 Configurable System-on-Chip (CSoC) device contains an embedded, performance-enhanced 8051 microcontroller. The E5 executes all 8051 instructions without modification. However, there is a specific case that requires special attention. The only E5 designs affected are those that …

Connect the 8051’s P2 PIO port to external logic, and
Use the 8051’s indirect addressing mode to access XDATA data space.

As shown in Table 1, only those designs that meet both criteria require special handling. Applications that meet one criterion, but not the other, operate without any special attention.

Table 1. Determining if Special Handling Required.

Use Indirect External Addressing?	P2 PIO Port Connects Externally?	Functions without Restrictions?
No	No	J
No	Yes	J
Yes	No	J
Yes	Yes	L! Special Handling Required

The remainder of this article provides background information on why these types of designs require special attention and potential solutions.

Connecting P2 to External Logic

The 8051 microcontroller within an E5 device is completely embedded, without any dedicated PIO ports. A soft module available in the FastChip Development System is required to connect any of the 8051’s PIO ports to external device pins. The “8032 PIO Port” soft module creates a PIO port that is exactly compatible with that found in the original 8051 device. However, this port is built using resources within the E5’s Configurable System Logic (CSL) matrix.

Figure 1 shows the FastChip graphical interface when the soft module is configured as PIO port P2. The register controlling the P2 PIO port is the 8051’s P2 Special Function Register (SFR), one of the 8051’s private registers.

Figure 1. The "8032 PIO Port" soft module provides a PIO port nearly exactly compatible with those found on the original 8051. However, there subtle nuances if using the P2 option and indirect addressing to XDATA space.

Because there are not any dedicated PIO ports on the E5, the P2 port is built in the E5’s CSL matrix. The CSL-based function must have access to the contents of the 8051’s private P2 SFR register. The E5 hardware allows this because the embedded 8051’s SFRs can be exported. When an SFR register is exported, the address and data for the SFR register is visible to the CSL matrix via the Configurable System Interconnect (CSI) bus socket. If a design uses the “8032 PIO Port” soft module to connect the P2 PIO port to external logic, FastChip automatically exports the P2 SFR and builds the appropriate logic to model the port.

If P2 PIO port does not connect to external logic, then the SFR is not exported to the CSL and it behaves just like it would on the original 8051 device.

Accessing Data in XDATA

The 8051 microcontroller has up to 64K-bytes of external data address space, called XDATA. The 8051 provides multiple methods to access XDATA, including both direct and indirect addressing modes.

Direct External Addressing

The most common method to access XDATA in an 8051 is using direct addressing. The 64K-byte XDATA region requires 16 address bits to uniquely decode a byte location. As shown in Figure 2, the 8051’s 16-bit pointer to external data is called DPTR. On the E5, there are actually two such data pointers. The second 16-bit data pointer is called DPTR1, defined by the two byte-wide SFR registers DP12 and DPL1. The DPS SFR register selects between the two data pointers.

Figure 2. Using direct addressing, the 16-bit DPTR data pointer points to a location in XDATA space.

To read a value from XDATA, the application program first loads the data pointer with the address of the data value. Then, the program uses the move external instruction (MOVX) to move the data, pointed to by DPTR, into the accumulator or vice versa.

Indirect Addressing

The 8051 microcontroller also provides an indirect addressing mode, typically used to access one of the 256 RAM locations available within the 8051 microcontroller. Some compilers call this region IDATA for indirectly addressed data.

Indirect addressing uses either register R0 or R1 within the 8051 as an 8-bit address pointer.

For example, to read a value from internal RAM, the address for the RAM location is loaded into either register R0 or R1. In this example, R0 is loaded with the 8-bit RAM address. A variant of the move instruction uses R0 as a pointer to RAM and loads the value at the specified location into the accumulator.

MOV R0, #ADDR8

MOV A, @R0

Indirect External Addressing

As described above, directly addressing XDATA address space requires a 16-bit data pointer. However, the code density of an application is improved by breaking the 64K-byte region into 256 pages of 256 bytes each. That way, the address for a particular XDATA location consists of a byte-wide page address and a byte-wide address within a page, as shown in Figure 3.

Figure 3. Indirect addressing to XDATA breaks the 16-bit address pointer into an 8-bit page address and an 8-bit byte address. The result is better code density.

Indirect External Addressing on the Original 8051

The 8051 architecture supports this type of indirect addressing to XDATA locations using the structure shown in Figure 4. The 8-bit page address is defined in the P2 SFR register. The 8-bit address within a 256-byte page is defined by either the R0 or R1 register.

Figure 4. Indirect addressing to XDATA on the 8051 uses the P2 SFR register as the page address and either R0 or R1 as the address within the page.

To access a specific byte within XDATA, the application program must load the P2 SFR register with the upper 8 bits of the 16-bit XDATA address. Then, the application program loads either R0 or R1 with the lower 8 bits of the 16-bit XDATA address. To read or write the location, the application program then uses a variant of the move external instruction (MOVX) that uses register R0 or R1 as the address pointer within the current 256-byte page, pointed to by P2. Figure 4 uses R0 but R1 would be similar.

Code density is improved using this technique because most data accesses are localized. Consequently, only an 8-bit pointer is used to address data for most accesses. The page pointer, P2, is modified more rarely.

Indirectly external addressing on the E5 works exactly the same way as on the original 8051, given that the P2 PIO does not connect externally. In other words, the E5 correctly handles indirect external addressing if the P2 SFR register is not exported.

Using Indirect External Addressing from a ‘C’ Compiler

Most 8051 ‘C’ compilers do not use indirect external addressing unless specifically instructed to do so. For example, using the Keil ‘C’ compiler, variables must either be specifically declared as paged data (PDATA) or the compiler must be specifically instructed to use the compact memory model.

Additionally, the P2 SFR register must be initialized with proper page address using the STARTUP.A51 startup program. Similarly, the starting address for PDATA must be specified for the linker.

The Problem: Indirect External Addressing and Externally Connecting P2

There is a specific problem in E5 applications that externally connect P2 as an 8051 PIO port and use indirect external addressing.

Because the P2 SFR register is exported in these cases, any indirect external addressing operations do not perform as expected. If P2 is exported, as shown in Figure 5, then the upper 8 bits of an indirect external address operation will always be 0xFF, regardless of the value loaded into P2. If P2 is exported, then indirect external addressing is limited to a single 256-byte page at the top of XDATA space.

Figure 5. If P2 is exported, then indirect external addressing operations may not perform as expected in an E5 application. Additionally, such operations may interfere with the E5’s Configuration Register Unit (CRU).

There is an additional complication because the upper 256 bytes of XDATA is also the default location of the E5’s Configuration Register Unit (CRU) that controls functions like the DMA controllers, the breakpoint unit, etc. Fortunately, the CRU region is relocatable if required.

Should a design require both externally connecting P2 as a PIO port and indirect external addressing, here are some recommended solutions in an E5 design.

Use Direct Addressing

Due to the complexities involved, Triscend does not recommend using indirect external addressing or PDATA on the E5. Instead, use direct addressing or XDATA for most applications. There is no need to use indirect external addressing unless absolutely required for code compatibility reasons with legacy 8051 application programs.

Though indirect external addressing has some performance advantages, the accelerated 8051 embedded within an E5 operates up to three times faster than the original 8051 at the same clock frequency. Direct addressing on an E5 is typically faster than indirect external addressing on the original 8051.

Use Another 8051 PIO Port, Not P2

If using external indirect addressing, avoid using P2 as a PIO port. For most ROM-less 8051 designs — i.e., 8031, 80C320, etc. — the P2 PIO port is the upper 8-bits of the external address to external memory. In the E5 device, this connection is not required because of the E5’s separate Memory Interface Unit (MIU). Likewise, most accesses to an external device mapped into XDATA space on an E5 device do not require the upper address lines because of the E5’s address Selectors.

If P2 is specifically required due to legacy code compatibility reasons, it may be possible to modify the source code to use P4 as the externally connected PIO port, preserving the code-density benefits of indirect external addressing. The P4 does not exist on the original 8051 but does on the E5 as SFR location 0xC0, as shown in Figure 1. The P4 port has the same capabilities as any of the original 8051’s ports, including bit addressibility. Even more options are available if bit addressibility is not a requirement. In these cases, the E5 supports additional PIO ports up to the number of available PIO pins.

Absolutely, Positively Need P2 and Indirect External Addressing

If an application absolutely requires externally connecting P2 and indirect external addressing, then build the E5 CSoC design accordingly. During an indirect external address, the upper 8 address bits will always 0xFF. Assign any CSL-based functions to appear in the top 256 bytes of XDATA. Move CRU elsewhere because by default its default location is in high memory. The CRU logical address is defined in the DMAP3_SRC register. In the FastChip address allocation file, be sure to prohibit the range of addresses where the CRU region resides, preventing FastChip from assigning any CSL logic in these locations.

In the same address allocate file, allocate CSL addresses so that they appear in upper 256 bytes.

Summary

E5 designs that both connect external logic to PIO Port P2 and use indirect external addressing require special handling. This article proposed various solutions for such designs.